Resolve Maven pin properties through profiles and nesting - #2020

Stacked on #2005, including its review fix (9765178). This closes the two Maven false-attestation gaps #2005 left open in VEX discovery.

1. Profile <properties> redefining a pin's property

Take a live <version>${v}</version> whose build resolution is the Socket pin. If any profile's <properties> redefine v, or any property v names, Maven resolves something else while that profile is active: it merges active profile properties over the pom's own before it interpolates. Vendored mode refuses to pin over such a property (version_override), but discovery attested it.

• PomScope now reads each profile's <properties>.
• Each PomDep gains version_alternatives: the other versions its build_version can take under any profile, or any set of profiles active together.
  • User properties and project.* / pom.* model references stay fixed.
  • A value that some set leaves unresolved, cyclic or too deep counts as the text as written.
• A new resolutions(d, in_profile) helper lists every version the build may resolve for a declaration: its build_version, then each alternative. It plugs into Stop attesting Maven pins a profile or user property overrides #2005's helpers in three places:
  • unpatched_classifier_copy: live and profile classifier copies and their classifier-keyed management.
  • profile_override, profile declarations: every version they can take is checked against the pin.
  • profile_override, live declarations: it now also walks live main-jar declarations, with the same main_jar_declarations scope and management-governs filter. A declaration whose build_version is the pin but has an alternative off it keeps the ref, marked unattested with the existing UnattestedKind::MavenProfileUnpatched. This applies to hosted pins and the pre-v5 vendored wiring alike. No new variant was needed; the variant doc, the CLI note text and CLI_CONTRACT.md are updated.
• A <profiles> declaration's own ${v} reads its own profile's <properties> first.

2. Property versions resolved one level deep

${a} with <a>${b}</a> now resolves through every property it names, in both views PomDep keeps since #2005:

• version (as the pom spells it, which hosted writes and rolls back): the model, then the declaration's own profile's <properties>, then the root <properties>.
• build_version (as the build resolves it): .mvn/maven.config -D user properties first, at every level. project.* / pom.* stay the model's.

It follows the vendored reactor's limits: at most 16 levels, and a cycle, an undefined name or an unterminated ${ never resolves. The version then stays as written, which is never a pin. Partly literal versions (${a}.${b}-x) resolve too, and ${project.version} resolves from the model in both views. #2005's MavenConfigOverride check (spelled vs built effective versions) therefore also catches a user property that redefines a nested property.

Shared interpolator

The vendored reactor's interpolator moves to formats/maven (still pure). That covers both interpolate_by and the duplicate body of Reactor::interpolate_with.

• It is now interpolate_strict, a single-valued wrapper over interpolate_each. interpolate_each enumerates every value a name can take, capped at 16 results.
• The reactor calls it with its own chain-walking lookup, and Reactor::interpolate drops its depth argument, which was always zero.
• New in both modes: explicit cycle detection, plus work bounds of 1024 lookups and 4096 bytes. A pom whose properties each name the next one many times over now fails closed instead of expanding exponentially.
• Vendored behavior is otherwise unchanged.

Tests

Each of these fails before this change:

• vex::discover::maven::tests::profile_properties_redefining_a_pin_property_are_not_attested covers the base release, a nested property, an undefined value, a self-cycle, two profiles that move the pin only together, a managed pin, and a user property that wins over every profile.
• vex::discover::maven::tests::profile_declaration_reads_its_own_profile_properties
• vex::discover::maven::tests::version_property_resolves_through_nested_properties covers a 16-deep chain (resolves), a 17-deep chain (does not), two cycles and nested user overrides.
• vex::discover::maven::tests::vendored_ref_under_profile_properties_is_not_attested
• formats::maven::tests::{version_properties_resolve_recursively_and_fail_closed, profile_properties_give_version_alternatives, interpolation_is_bounded}. These also assert that a nested user property moves build_version but not version.

Changed expectation after the rebase. In version_property_resolves_through_nested_properties, the case where the pom resolves the base release and -Dp1=<pin> in .mvn/maven.config supplies the pin through a nested property now expects no attestation. Under #2005's review fix, a Socket version that only maven.config supplies is not pom.xml wiring: hosted never writes one and rollback / remove never edit .mvn/maven.config. It is diagnosed (patched_ref_unattributable), never a ref. Nested resolution now applies that rule to nested properties too.

Runs, on the rebased branch (ec89bd9):

• cargo test -p socket-patch-core --lib -- vex::discover:: formats::maven vendor::jvm:: passes 715. patch::redirect:: together with the golden test passes 872.
• The golden corpus is unchanged (committed_fixture_corpus_matches_golden passes).
• cargo test -p socket-patch-cli --lib vex_sources passes 14.
• cargo clippy --locked --workspace --all-features -- -D warnings and cargo fmt --all -- --check are clean.

Not done

• Coordinates moved by profile properties. A <groupId> / <artifactId> that is a property a profile redefines is the same class of gap; it is handled in Withhold Maven pins whose coordinates a profile redefines #2026, stacked on this branch.
• Activation is not evaluated. Every profile counts, as in vendored mode.

🤖 Generated with Claude Code